Summary

Bandaid for #283 plus four bundled fixes for signup-flow issues discovered during follow-up ad-hoc testing (see .claude/notes/2026-05-20-signup-flow-adhoc-findings.md).

Original bandaid (#283)

/signup/submit was non-atomic — 8 sequential HTTP calls inside one try/except — so any transient failure after add_member succeeded would abort the redirect to /signup/payment and strand the user with a half-created row.

• Critical path (get_access_token, get_member_id, add_member) still bounces the user to /signup on failure.
• Once add_member returns a member_id, the seven secondary JSONB writes run in a for-loop with per-step try/except. Each step logs success at INFO and failure at ERROR; the loop never throws.
• User always reaches /signup/payment once the row exists.
• Bumped seven secondary helpers in dhservices.py from timeout=10 → timeout=20.

Bundled fixes (signup-flow hardening, all caused-or-worsened by the bandaid)

Out of scope (separate follow-ups)

Filed as #292 (enumeration + rate-limit), #293 (server-side validation), #294 (/signup/payment arbitrary email), #295 (XSS render audit), #296 (logged-in user can create orphan members). None are bandaid-related.

Tests completed

All run live on dev with the rebuilt dh_member_portal + dh_service + dh_st2dh containers.

Bandaid core

• Happy path signup walks email → form → /signup/payment; Stripe pricing-table iframe renders both tiers
• DB row populated across all 8 JSONB columns after a successful signup
• Per-step log lines verified: Created new member with ID: N + 7× Signup member N: <label> initialized
• Inline-raise fault injection: forms + notes forced to fail mid-loop — user still reaches /signup/payment, those two columns are null, other 5 populated, ERROR log lines surfaced
• Per-step fault injection across all 7 scaffolding steps individually (connections / status / forms / notes / access / authorizations / extras): each one fails cleanly, user always reaches /signup/payment, exactly the one targeted column is null and the other six are populated
• CSRF protection: missing or bogus token → 302 to /signup, no row created
• Existing-email path still returns "A member with this email already exists" flash

Finding 10 — membership_status None guard (a64fcce)

• Manually-inserted member with status = NULL: dev-login + /dashboard renders without AttributeError: 'NoneType' object has no attribute 'lower'
• Bandaid-produced status-null member (from per-step fault test): dev-login + walks all 5 dashboard pages (/dashboard, /dashboard/profile, /dashboard/keys, /dashboard/auths, /dashboard/storage, /dashboard/floof), every page HTTP 200, zero AttributeError in logs
• Regression sweep across all 4 legitimate statuses (active/pending/suspended/banned seed members): every dashboard page returns HTTP 200, banned-gate correctly redirects banned member's /dashboard* URLs to /dashboard/locked, zero AttributeError in logs
• Unit-tested the ((dict or {}).get(key) or '').lower() expression against all 4 input shapes (status=None, status[ms]=None, missing key, normal value)
• Patch sites covered: 4 in code/DHMemberPortal/app.py + 1 in code/external/ST2DH/app.py

Finding 5 + 14 — narrow session reset + flash rendering (67c3195, 657e93d)

• Dev-login as a seed member → visit /signup → /dashboard still HTTP 200 (was 302 → /)
• Logged-in user GET /signup no longer logs them out (Finding 5 confirmed end-to-end)
• Duplicate-email POST flow: redirect to /signup → flash "A member with this email already exists" now renders on signup_email.html
• Logged-in user POSTs /signup/submit with their OWN email → HTTP 302 → /signup (correctly routed through the "already exists" path; zero duplicate rows created)

Finding 7-username + 9 — server-side username uniqueness (2fdbcd9)

• username=alovelace (exact case match against seed): rejected with "That username is already taken" flash, zero DB rows created
• username=ALOVELACE (case-insensitive match): rejected the same way, zero rows
• Confirms Determine RFID Entry Retention Policy #9 (concurrent same-username different-email) is also closed: both racing requests now hit the username check before add_member

Finding 8 — advisory lock on same-email INSERT (72f8abe)

• Two parallel same-email POSTs: exactly one member row in DB; advisory lock serializes them so it's no longer possible to get two rows or to silently overwrite one side's identity
• Stress: 15 concurrent same-email POSTs → exactly one member row created; 1 request reached /signup/payment, 14 routed to /signup "already exists". Zero deadlocks, zero lock-wait errors, zero exceptions in DHService or portal logs. Total completion: 8.4s (~550ms per serialized lock acquisition).

Test plan

Pre-merge — held until external prereqs exist

• ST2DH webhook simulation — not feasible without real Stripe credentials. ST2DH calls stripe.Customer.retrieve(customer_id) against the live Stripe API to look up the customer's email; that fails immediately in a credential-less dev environment. Worth running once a dev Stripe test account is configured.

Post-merge / production

• Watch for any new signup-related error log lines in prod once deployed
• Verify status->>'stripe_product_id' lands as expected via the ST2DH webhook for a real new signup
• Spot-check update_member_access from the dashboard Keys tab still saves within the 20s ceiling

Known trade-offs

• update_member_access is also used by the dashboard Keys page profile save. The 20s timeout now applies there too. The worst case is a 20s synchronous Flask wait on a real DHService timeout (previously 10s); normal writes are sub-second.
• The "Sign up successful! Please complete payment." flash fires even if all 7 scaffolding steps failed. By design: user is unblocked, admin tooling addresses the partial row later. Finding 10 ensures the partial row no longer crashes the dashboard.

🤖 Generated with Claude Code